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Description 


This paper is the third in a series of pap2rs 
that make up a recommendation for the AX.25 
Network Sublayer protocol. 


The purpose of this paper is to describe 
optional user facilities requested of the network 
or called DTE at time of a call request. Included 
in these facilities are standard CCITT recommended 
facilities, and additional amateur network 
facilities. The amateur facilities are 
suggested by the draft committee, reader 
suggestions or comments are invited. 


Comments may be sent to the author, or sent 
to the AMRAD Newsletter for publication. Follow 
the AMRAD Newsletter for further details. 
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Procedures and formats for optional user 
Facilities ate packet Ievel 


7.1 Procedures for optional user facilities 
associated with virtual Call service 


Teall Extended packet sequence numbering 


pee facility is not presently allowed in 
AX. 


Weedson Nonstandard default window sizes 


_ Nonstandard default window sizes is an 
optional user facility agreed to for a period of 
time. This facility, if subscribed to, provides 
for the selection of default window sizes from the 
list of window sizes supported. Some networks may 
constrain the default window sizes to be the same 
for each direction of data transmission across the 
DTE/DCE interface. In the absence of this 
facility, the default window sizes are 2. 


Values other than the default window sizes 
may be negotiated for a virtual call by means of 
ice ar emacs parameter negotiation facility 

see 7.2.2). 


Teds Default throughput classes assignment 


This optional facility is not implemented in 


AX.25 
7.1.4 Packet retransmission 

This optional facility is not implemented in 
AX.25. 
hedhed Incoming calls barred 

This optional facility is not implemented in 
AX.25. 
7.1.6 Outgoing calls barred 


This optional facility is not implemented in 
AX.25. 


7.1.7 One-way logical channel outgoing 


One-way logical channel outgoing is an 
optional user facility agreed to for a period of 
time. This user facility, if subscribed to, 
restricts the logical channel use to originating 
outgoing virtual calls only. 


A logical channel used for virtual calls 
retains its full duplex capability. 


The rules according to which logical channel 
group numbers and logical channel numbers can be 
assigned to one-way outgoing logical channels for 
virtual calls are given in Annex A. 


If all the logical channels for virtual calls 
are one-way outgoing at a DTE/DCE interface, the 
effect is equivalent to the incoming calls barred 
facility (not implemented). 


7.1.8 One-way logical channel incoming 


One-way logical channel incoming is an 
optional user facility agreed to for a period of 
time. This user facility, if it is supported, 
restricts the logical channel use to receivin 
incoming virtual calls only. A logical channe 
used for virtual calls retains its full duplex 
capability. 


The rules according to which logical channel 
group numbers and logical channel numbers can be 
assigned to one-way incoming logical channels for 
virtual calls are given in Annex A. 


If all the logical channels for virtual calls 
are one-way incoming at a DTE/DCE interface, the 
effect is equivalent to the outgoing calls barred 
facility (not implemented). 


Peleg. Closed user group 


This optional facility is not supported. 


7.1.10 Closed user group with outgoing access 
This optional facility is not available in 


7.1.11 Closed user group with incoming access 
This optional facility is not available in 


hekigk’ Incoming calls barred within a closed 
user grou 


ee optional facility is not available in 
AX.25. 


TANTS Outgoing calls barred within a closed 
user group 


; This optional facility is not available in 
AX.25. 


7.1.14 Bilateral closed user group 


This optional facility is not available in 
AX.25. 


Leeks Bilateral closed _user group with 
outgoing ac cess es 


. This optional facility is not available in 
AX.25. 


7.1.16 Reverse charging 


Reverse charging is an optional user facility 
which mav be requested by a DTE for a given 
virtual call (see 7.4.2.3), and only for the case 
of a virtual call destined for a DTE on a public 
data network. 


Dede ld Reverse charging acceptance 
This optional facility is not available in 


AX.25 
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71.18 RPOA selection 


Recognized private operating agency (RPOA) 
selection is an optional user facility which may 
be requested by a DTE for a given virtual call. 


When this user facility is requested, it 
provides for the user specification by the 
calling/source DTE of a particular RPOA transit 
network through which the call is to be routed 
internationally, when more than one RPOA transit 
network exists at a gateway (see 7.4.2.4). 


7.2 Procedures for optional user facilities only 
available with virtual call services 


Dei T Nonstandard default packet sizes 


Nonstandard default packet sizes is an 
optional user facility agreed to for a period of 
time. This facility, if subscribed to, provides 
for the selection of default packet sizes from the 
list of packet sizes supported. Some networks ma 
constrain the packet sizes to be the same for eac 
direction of data transmission across the DTE/DCE 
interface. In the absence of this facility, the 
default packet sizes are 128 octets. The term 
"packet sizes" refers to the maximum user data 
field lengths of DCE and DTE data packets. 


Values other than the default packet sizes 
may be negotiated for a virtual call by means of 
the flow control parameter negotiation facility 
(see 7.2.2) 


Teled Flow control parameter negotiation 


Flow parameter negotiation is an optional 
user facility agreed to for a period of time which 
can be use b a DTE on virtual calls. This 
facility, if sub scribed to, permits negotiation on 
a per-call basis of the flow control parameters. 
The flow control parameters considered are the 
packet and window sizes at the DTE/DCE interface 
for each direction of data transmission. 


"Packet sizes" in 7.2.2 refers to the maximum 
user data field lengths of DCE and DTE data 
packets. 


In the absence of the flow control parameter 
negotiation facility, the flow control parameters 
to be used at a particular DTE/DCE interface are 
the default packet sizes (see 7.2.1) and the 
default window sizes (see 7.1.2). 


When the calling DTE has subscribed to the 
flow control parameter negotiation facility, it 
may separately request packet sizes and window 
sizes for each direction of data transmission (see 
7.4.2.5). If a particular window size is not 
explicitly requested in a call request packet, the 
DCE will assume that the default window size was 
requested. If a particular packet size is not 
explicitly requested, the DCE will assume that the 
default packet size was requested. 


When a called DTE has subscribed to the flow 
control parameter negotiation facility, each 
incoming call packet will indicate the packet and 
window sizes from which DTE negotiation can start. 
No relationship needs to exist between the packet 
sizes (P) and window sizes (W) requested in the 
call request packet and those indicated in the 
incoming call packet. The called DTE may request 
window and packet sizes with facilities in the 
call accepted packet. The only valid facility 
requests in the call accepted packet, ee a 
function of the facility indications in 
sneomine call packet, are given in Table 13) Ax. 25 
(Table 13/AX.25 is at the end of this paper). If 
the facility request is not made in the call 
accepted packet, the DTE is assumed to have 
accepted the indicated values (regardless of the 
default values). 


When the calling DTE has subscribed to the 
flow control negotiation facility, every call 
connected packet will indicate the packet and 
window sizes to be used at the DTE/DCE interface 
for the call. The only valid facility indications 
in the call request packet are iven in Table 
14/AX.25 (Table 14/AX.25 is at the end of this 


paper 


The network may have constraints requiring 
the flow control parameters used for a cal 


modified before indicating them to the DTE in the 
incoming call packet or call connected packet; the 
ranges of parameter values available on various 
networks may differ. 


Window and packet sizes need not be the same 
at each end of a virtual call. 


The role of the DCE in aaelenen ee the flow 
control parameters may be network dependan 


W238 Throughput class negotiation 


This parameter is not presently implemented 
in AX.25. 


Ti2 <A East select 


Fast select is an optional user facility 
which may be requested y a DTE for a given 
virtual call. 


DTEs can request the fast select facility on 
a per-call basis by means of an appropriate 
facility request (see 7.4.2.7) in a call request 
packet using any logical channel which has been 
assigned to virtual calls. 


The fast select facility, if requested in the 
call request packet and if it indicates no 
restriction on response, allows this acket to 
contain a call user data field of up to 128 octets 
and authorizes the DCE to transmit to the DTE, 
during the DTE waiting state, a call connected 
packet with a called user data field of up to 128 
octets or a clear indication packet with a clear 
user data field of up to 128 octets. 


The fast select facility, if requested in the 
call request packet and if it indicates 
restriction on response, allows this packet to 
contain a call user data field of up to 128 octets 
and authorizes the DCE to send to the DTE, during 
the DTE waiting state, a clear indication packet 
with a clear user data field of up to 128 octets, 
the DCE would not be authorized to transmit a call 
connected packet. 


The presence of the fast select facility 
indicating no restriction on response in an 
incoming call packet permits the DTE to issue as a 
direct response to this packet a call accepted 
packet with a called user data field of up to 128 
octets or a clear request packet with a clear user 
data field of up to L8 octets. 


The presence of the fast select facility 
indicating restriction on_response in an incoming 
call packet permits th.e DTE to issue as a direct 
response to this packet a clear request packet 
with a clear user data field of up to 128 octets 
the DTE would not be authorized to send a cal 
accepted packet. 


A clear request packet with a clear user data 
field of up to 128 octets at any time other than 
the DCE waiting state (p3) is not allowed. 


The call user data field, the called user 
data field, and the clear user data field will not 
be fragmented for delivery across the DTE/DCE 
interface. 


The significance of the call connected packet 
and the clear indication packet with the cause 
“DTE originated” as a direct response to the call 
request packet with the fast select facility is 
that the call request packet with the data field 
has been received by the called DTE. 


All other procedures of a call in which the 
fast select facility has been requested are the 
same as those of a virtual call. 


If a fast select clear re uest packet with a 
non-zero address length fiel8 or facility length 
field is received, the DCE shall discard the 
received packet. The DCE shall indicate clearing 
by sending to the DTE a clear indication packet 
with a cause "Local procedure error" and 
diagnostic #74 or #75, as appropriate. The 
distant DTE is also inf’ormed of the clearing by a 
clear indication packer, with the cause "Remote 
procedure error" (same diagnostic). 
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Te2s5 Fast select acceptance 


This optional pati) is not implemented in 
AX.25. All users should allow fast select. 


7.2.6 Charging information 


This optional facility is not implemented in 
AX. 25. 


7.2.7 D bit modification 


This optional facility is not implemented in 
AX. 25. 


7.2.8 Hunt. group 


Hunt group is an optional user facility 
agreed to for a period of time. This user 
facility, if subscribed to, distributes incoming 
calls having an address associated with the hunt 
group across a designated grouping of DTE/DCE 
interfaces. 


Selection is performed for an incomin 
virtual call if there is at least one idle logica 
channel available for virtual calls on any DTE/DCE 
interface in a group. Once a virtual call is 
assigned to a DTE/DCE interface, it is treated as 
a regular call. 


When virtual calls are placed to a hunt group 
address in the case specific addresses have also 
been assigned to the individual DTE/DCE 
interfaces, the call connected or clear indication 
packet sent to the calling DTE will optionally 
contain the called address of the selected DTE/DCE 
interface and the called line address modified 
notification facility indicating the reason why 
the called address is different from the one 
originally requested. 


Virtual calls may be originated on DTE/DCE 
interfaces belonging to the hunt group; these are 
handled in the normal manner. In particular, the 
calling DTE address transferred to the remote DTE 
in the incoming call packet is the hunt group 
unless the DTE/DCE interface has a specific 
address assigned. Some networks may place a limit 
on the number of DTE/DCE interfaces in the hunt 
group, and/or constrain the size of the geographic 
region that can be served by a single hunt group. 


7.2.9 Call redirection 


Call redirection is an optional facility 
agreed to for a period of time. This user 
facility, if subscribed to by a DTE, redirects 
incoming calls destined to this DTE, when: 


1) the called DTE is out-of-order, or 
2) the called DTE is busy. 


Some networks may provide call redirection 
only in the case of 1) above. 


In addition, some networks may offer: 


3) systematic call redirection with prior 
request of the called DTE. 


The basic service is limited to one call 
redirection. In addition, some networks may offer 
either one of the following (mutually exclusive) 
capabilities: 


A) A list of alternate DTEs (cl, c2,c¢3, ...etc) 
is stored by the network of thé originally 
called DTE Ore B) consecutive attempts o 
call redirection are tried to each of these 
addresses, in the order of the list, up to 
the completion of the call; 


B) Call redirections may be logically chained; 
if DTE C has subscribed to call redirection 
to DTE D, the call ney be redirected to D 
even if it was originally addressed to B. 


In any case, networks will ensure that loops 
are avoided and that connection establishment 
phase has a limited duration. 


If a call is cleared by the network as a 
consequence of the actions taken to this effect, 


the clearing cause is the one generated at the 
last DTE/DCE interface. 


When the virtual call is redirected, the call 
connected or clear indication packets sent to the 
calling DTE will contain the called address of the 
alternate DTE and the calling line address 
modified notification facility, indicating the 
reason why the called address is different from 
the one originally requested. 


When the virtual call is redirected, some 
networks may indicate to the alternate DTE the 
reason for redirection and the address of the 
originally called DTE, using the call redirection 
notification facility in the incoming call packet. 


The order of call set-up processing at the 
originally called DCE as well as the alternate DCE 
will be according to the sequence of call progress 
signals in Table 1/AX.96. For those networks that 
provide systematic call redirection with the prior 
re uest of the called DTE, the systematic call 
re8irection request will have the highest priority 
in the call set-up processing sequence at the 
originally called DCE. 


7.2.10 Called line -address modified 
“Hotification Se hee 


Called line address modified notification is 
a user facility, used by the DCE in the call 
connected or clear indication packets to inform 
the calling DTE as to why the called address, if 
present, in these packets is different from that 
specified in the call request packets. 


The following reasons can be indicated with 
the use of called line address modified 
notification facility: 


1) Call distribution within a Hunt Group. 


2) Call redirection due to originally called DTE 
out of order. 


3) cal! redirection due to originally called DTE 
usy. 


4) Call redirection due to prior request from 
the originally called DTE for systematic call 
redirection. 


2d Call redirection notification 


Call redirection notification is a user 
facility, used by the DCE in the incoming call 
packet to inform the alternate DTE as to w the 

call is redirected, and the address o the 
originally called DTE. 


The following reasons can be indicated with 
the call redirection notification facility: 


1) Call redirection due to originally called DTE 
out of order. 


2) ae redirection due to originally called DTE 
usy. 


3) Call redirection due to prior request from 
the originally called DTE for systematic call 
redirection. 


7.2.12 Amateur networking facilities 


The following describes optional, amateur 
radio networking facilities. These facilities are 
interim recommendations, subject to corrections. 


One of the two amateur routing facilities 
must be provided when connections are requested 
outside the local network. 


7.2.12.1 Amateur network facility marker 


The amateur related networking optional 
facilities must follow the CCITT optional 
facilities, and shall be separated from the CCITT 
facilities by a special two octet amateur marker. 


7.2.12.2 Amateur explicit routing facility 


The amateur explicit routing facility is an 
optional user facility that allows the calling DTE 
to specify the route of a connection. 


When this facility is selected, the calling 
DTE must provide a list of addresses which will be 
used by the network to route the call to the 
called DTE. 


7.2.12.3 Amateur implicit routing facility 


The amateur implicit routing facility is an 
optional user facility that allows the network to 
route the call based on geographical information 
supplied by the calling DTE. 


When this facility is selected, the calling 
DTE must provide the geographical location of the 
called DTE. 


Ts2s13 Additional optional facilities 


In addition to the above facilities, others 
may be added as necessary. Subject for further 
study are certain X.75 utilities, such as call 
control. 


coptional user facilities only 
atapram service 


7.3 Procedures for 
available with 


These facilities are not implemented in AX.25 


7.4 Formats for optional user facilities 
AST General 


The facility field is present only when a DTE 
is using an optional user facility requiring some 
indication in the call request, incoming call, 


call accepted, call connected, clear request, or 
clear indication. 

The facility field contains one of more 
facility elements. The first octet of each 
facility element contains a facility code to 
indicate the facility or facilities requested. 

The facility codes are divided into four 
classes, by making use of bits 8 and 7 of the 


facility code field, in order to specify facility 
parameters consisting of 1, 2, 3, or a variable 
number of octets. The general class coding of the 
facility code field is shown in Table 15/AX.25 
(Table 15/AX.25 is at the end of this paper). 


For class D the octet following the facility 


code indicates the length, in octets, of the 
facility parameter field. The facility parameter 
field length is binary coded, with bit 1 being the 


low order bit. 


The formats for the four classes are shown in 
Table 16/AX.25. 


The facility code field is binary coded ana 
without extension, provides for a maximum of 64 
facility codes for classes A, B, and C, and 63 
facility codes for class D giving a total of 255 


facility codes. 

Facility code 11111111 is reserved for 
extension of the facility code. The octet 
following this octet indicates an extended 
facility code having the format A, B, C, or D as 
define above. Repetition of facility code 
11111111 ais permitted and thus additional 


extensions may result. 


The codin 
dependent on the 


of the facility parameter field is 
facility being requested. 


A facility code may be assigned to identify a 
number of specific facilities, each having a bit 


in the parameter field indicating facility 
requested/facility not re quested. In this 
situation, the parameter fiel is binary encoded 
with each bit position relating to a specific 


facility. A 0 indicates that the facility related 
to the particular bit is not requested and a 1 


indicates that the facility related to the 
particular bit is requested. Parameter bits not 
assigned to a specific facility are set to 0. If 


none of the facilities represented by the facility 
code are requested for a virtual call, the 
facility code and its associated parameter field 
need not be present. 


A facility marker, consisting of a single 
octet pair, is used to separate requests for AX.25 
facilities, as defined in this section, from 
requests for non-AX.25 facilities that also may be 
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7.4.2.4 


offered by a network. The first octet is a 
facility code and is set to zero, and the second 
octet is the facility parameter field. 


The coding of the parameter field will be 
either all zeros or all ones depending on whether 
the facility requests following the marker refer 
to facilities offered calling/source or 
called/destination network, respectively. For 
intranetwork virtual calls, the parameter field 
should be all zeros. 


Requests for non-AX.25 facilities offered by 
the calling/source and called/destination networks 
may Simultaneously present within the facilit 
field and in such cases two facility markers wild 
be required with parameter fields coded as 
described above. 


Within the facility field, requests for AX.25 
facilities will precede-all requests for non-AX.25 
facilities and facility markers need only be 
present when requests for non-AX.25 facilities are 
present. 


Class A Class B 


bits 87654321 


bits 8765 4321 


00 H 00xX XXX XxX ! 0 0 : O1l1XXXxX XX ! 
Cc Pewee ener een nr eee -! Cc [emmv nnn ren nocnwen 
T ! Facility ! Tey at Facility ! 
E 1! Parameter Field ! E ewe am} 
T meer eee een en nne T 2 ! Parameter Field ! 


Class C Class D 


bits 8 7 6 54 32 1 


bits 87654321 


oo!l1loOxXxXxXxxx! 0 o!tilixxxxxx! 
Cc {------ a---m----=- Cc lecceecescca=s———> ' 
T1! Facility ! T 1! Facility ! 
fees eel. ‘a -< ese ry 
T 2 H Parameter i To 2 Parameter ! 
31 Field ~ ! Vo fees Field -1-75 

eee we mew meow encene A! 
Reo eo eee ee 

Table 16/AX.25 

Facility Class Coding 

1.4.2 Coding of facility field for particular 


facilities 


Coding of RPOA selection facility 


7.4.2.4.1 Facility code field 


The coding of the facility code field for 
RPOA selection is: 


bit: 8 
code: 0 
7.4.2.4.2 Facility parameter field 


The parameter field contains the data network 
identification code for the requested RPOA transit 
network, and is in a form of four decimal digits. 


Each digit is coded in a semi-octet (nibble) 
in binary coded decimal wit& bit 5 of the first 
octet being the low order bit of the first digit, 
bit 1 of the first octet being the low order bit 
of the second ap oe bit 5 of the second octet 
being the low order bit of the third digit, and 
bit 1 of the second octet being the low order bit 
of the fourth digit. 


1.4.2.5. Coding of flow control parameter 
facility négotiation 


The coding of the facility code field and the 
format of the facility parameter field for packet 
sizes are the same in call request, incoming call, 
call accepted, and call connected packets. 


7.4.2.5.1.1 Facility. code field 


_. The coding of &he facility code for packet 
sizes is: 


bit: 87654321 
code: 01000010 


7,4.2.5.1.2_ Facility parameter field 


The packet siz for the direction. of 
transmission from the called DTE is indicated in 
bits 4, 3, 2, and 1 of the first qautett. The 
packet size for the direction of ia le from 
the calling DTE is indicated in bits 4, 3, and 
1 of the Second octet. Bits 5, 6, 7, etal "8 of 
each octet must be zero. 


The four bits indicating each packet size are 
binary coded and express the logarithm base 2 of 
the number of octets of the maximum packet size. 


Networks may offer values from 4 to 12, 
ee cong Pa to packet sizes of 16, 32, 64, 128) 
256, 512. TAS. 2048, or 4096, ora Subset of 
thete values: All’ networks’ should provide a 
packet size of 128. 


7.4.2.5.2 Coding for window sizes 


The coding of the facility code field and the 
format of the facility parameter field for window 
sizes are the same in call request, incoming call, 
call accepted, and call connected packets. 


7.4.2.5.2.1 Facility code field 


The coding of the facility code field for 
window sizes is: 


bit: 87654 
code: O10 0 


321 
00011 


7.4.2.5.2.2 Facility parameter field 


The window size for the direction of 
transmission from the called DTE is indicated in 
bits 7 to 1 of the first octet. The window size 
for the direction of transmission from the callin 
DTE is indicated in bits 7 to 1 of the secon 
octet. Bit 8 of each octet must be zero. 


The bits indicating each window size are 
binary coded and express the size of the window. 
A value of zero is not allowed. 


Window sizes of 8 to 128 are not allowed in 
AX.25. All networks will provide a window s1ze of 


7.4.2.7 Coding of fast select facility 


The coding of the facility code and parameter 
fields for fast select is the same in call request 
and incoming call packets. 


7.4.2.7.1 Facility code field 


The coding of the facility code field for 
fast select is: 


bit: 87654321 
code: 00000001 


7.4.2.7.2 Facility parameter field 
; The coding of the facility parameter field 
is: 
Bit 8=0 and bit 7#=0 or 1 for fast select not 
requested. 


Bit 8=1 and bit 7=0 for fast select requested 
with no restriction on response. 


Bit 8=1 and bit 7=1 for fast select requested 
with restriction on response. 


Bits 6, 5, 4, 3, and 2 may be used for other 
facilities. if not they are set to zero. 
Use of bit 1 is described in section 7.4.2.3. 


7.4.2.11 Voding oft cared Line address modified 
= HOETE 


ification 


Phicd TL 


7.4.2,11.2 


Facility code field 


oding of the, facility code field for 
called tine address modifie notification is: 


bit: Ga hae ee 
code : 00001000 


Facility parameter field 


The coding of the facility parameter field 
for called line address modified notification is: 


bits: 87654321 
000001141 Call distribution within 
a Hunt Group. 

000000041 Call redirection due to 
cree called DIE 
bus 
0000310041 Call redirection due to 
originally called DTE 

out of order. 
0000111 1 Call redirection due to 
prior request from 
na 


originally called D 
for systematic cal 
redirection. 


7.4.2.12 Coding of call redirection notification 


TsA2s TQ 


The, coding of the facility code field for 
call redirection notification is: 


bit: 87654 32 1 
code: 11000011 


Facility parameter field 


The octet following the facility code field 
indicates the length in octets of the facility 
parameter field and has the value n+2 where n is 
the number of octets necessary to hold the 
originally called DTE address. 


Facility code field 


The second octet indicates the reason for the 
call redirection and has one of the following 
values: 


bits: 87654321 
00000001 Originally called DTE 


00001001 Originally called DTE 
out of order 

000014111 Svstematiccall 
redirection 


The third octet indicates, in bits 4, 3,2, 
and 1, the number of nibbles in the originally 
called DTE address. This address Length indicator 
is binary coded, with bit 1 being the low order 
bit. Bits 8, 7, 6, and 5 of this octet are set to 
zero. 


The following octets to eae cones 
the ports tnelty called . E address, coded 
identically to the called ane address field in the 
call request packet (see 6.2.1.3). 


7.4.13 Coding of amateur network facilities 


7.4.13.1 Godingor the: amateurnetwork 
facilr tess marker 


The amateur network facilities marker field 
consists of two octets and is coded as folows: 


bits: 87654321 
octetl: 0 0 00000 
octet2: 11111110 


co} 


7.4.13.2 Coding of amateur network explicit 
routing facility 


7.4.13.2.1 Facility code field 


The coding of the facility code field for the 
amateur network explicit routing is: 


bits: 87654321 
code: 11000000 
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7.4.13.2.2 Facility parameter field 


The coding of the facility parameter field in 
the amateur network explicit routing facility is 
as follows: 


The first octet is called the explicit length 
octet., and contains the total length of the 
facility, including the code field and the length 
octet. This length octet is binary coded, and 
cannot be zero. 


The octets following the length octet contain 
the packet switch identifier(s) that indicate 
which switches the call should progress through. 


The packet switch identifier consists of the 
six unshifted ASCII characters of the amateur 
callsign a2 ag case alpha and numeric characters 
only) of the packet switch, followed by an 
additional octet that contains a five-bit station 
subaddress. The station subaddress information is 
contained in bits 5, 4, 3, 2, and 1 of the seventh 
octet. Bits 8, 7, and 6 of the subaddress octet 
are reserved, and set to zero. If the callsign 
contains less than six ASCII characters, the 
callsign will be padded with trailing ASCII spaces 


between the last callsign character and the 
subaddress. 

Up to 38 packet switch identifiers are 
allowed, the first identifier will identify the 
first packet switch in the chain. Additional 


switch identifiers following the first in order of 
call progress from the calling DTE to the called 
DTE. 


Other methods of explicit routing a 


subject for further study. 


are 


7.4.13.3 Coding of amateur network implicit 
routing-facility 


7.4.13.3.1 Facility code field 


The coding of the facility code field for the 
amateur network implicit routing facility is: 
continued next column.... 


{Facility indication! 
| 


Valid facility reques 


4321 
O10 OL 


7.4.13.3.2 Facility parameter field 


The coding of the facility parameter field 
for the amateur network implicit routing facility 
consists of three octets. 


arameter is a subject for 
further = study. The following information is one 
suggested method of coding this information, based 
on the geographical location of the called DTE. 


The coding of this 


The first octet contains the Lorg itude i 
degrees of the called station, from to 180 
based on Greenwich, England. This octet is binary 
encoded, with bit 8 being the most-significant 
bit, and bit 1 the least-significant bit. 

The second octet contains the Latitude of the 
called station in degrees. Bit 8 indicates 


whether the called DTE is north or south of the 
equator (zero equals north, one equals south). 
Bits 7 to 1 contain the Latitude in degrees, from 
0 to 89. This data is binary coded, with bit 7 
being the MSB, and bit l is the LSB. 


The third octet contains an east/west marker 


bit, and grid information within the 
Latitude/Longitude specified. 
Bit 8 of the third octet contains the 


east/west marker for the Longitude information. 
If bit 8 is a zero, the Longitude information is 
west of Greenwich, while a one indicates the 
information is east of Greenwich. 


The remaining seven bits contain information 
on where within the square (resulting from the 
Latitude/Longitude information above) the station 
is located. Actual coding of this field is a 
subject for further study. 


Other methods of encoding the amateur network 
implicit routing facility are subject to further 
study. One method might be to use National 
Traffic System abbreviations. Comments or 
suggestions are welcome. 


! Wh accor eas =>2 ! W(indicated) =>W(requested) =>2! 
! W(indicated) = 1 \ W(requested) = 1 or 2. ' 
Fl ladaladeteietateteieetaneieital a anna a ad i 
a estate =>128 ! P(indicated) fede ieee erty 
1P(indicated) < 128 !128 =>P(requested) =>P(indicated)! 


Table 13/AX.25 


Valid facilit 


requests in call accepted packets 


in response to facility indications in incoming call packets 


bee Sem ee 
! Weediesres) =>2 ! Wee Hale =>W(indicated) =>2 ! 
! W(requested) = 1 ! Wlindicated) = i or 2 ! 
Lemme meme new enn mw nnn | SSS SSS SSS SSS SSeS ! 
Pet reauested) =>128 ! P(requested) =>P(indicated)=>128! 
1P(requested) < 128 !128 =>P(indicated) =>P(requested)! 


wwe ewe mmm ew ew ew mee wwe ee we eee mene eee eee sees ees 


Table 14/AX.25 
Valid facility indications in call connected packets 
in response to facility requests in call requests packets 


parameter 


ew ew ee we ww ewe ee ene nme nee ser nneeree! 


for sing le octet parameter 


for double octet parameter 


for triple octet parameter ! 


for variable lenght param. 


! Class !87654321 

!Class A !00xX XXX XxX 

! Class B!0Q01xXxX XX XxX 

! Class C !10xXxX XX XxX 

{Class D! 11x XXX Xx 
Where X 


can be either a zero or one. 


Table 15/AX.25 
Facility Class Coding 


3.43 


